jQuery 2.0 Released

Posted on by

You asked for it, you got it: jQuery 2.0 has arrived!

As promised, this version leaves behind the older Internet Explorer 6, 7, and 8 browsers. In return it is smaller, faster, and can be used in JavaScript environments where the code needed for old-IE compatibility often causes problems of its own. But don’t worry, the jQuery team still supports the 1.x branch which does run on IE 6/7/8. You can (and should) continue to use jQuery 1.9 (and the upcoming 1.10) on web sites that need to accommodate older browsers.

Where to Get It

The final jQuery 2.0.0 files can be found here on the jQuery CDN:

The files should also be available on the Google and Microsoft CDNs soon, but please give these folks a few days before releasing a storm of impatient tweets. Also remember that production web sites should be requesting a specific version from any CDN; using a non-specific version like /2/ or jquery-latest.js is considered harmful to your web site’s health and performance.

If you’re upgrading from a version before 1.9, we recommend that you use the jQuery Migrate plugin and read the jQuery 1.9 Upgrade Guide, since there have been a lot of changes. It’s easy to use the plugin, just include it in your HTML file after jQuery and open your browser console to see the messages it generates:

<script src="http://code.jquery.com/jquery-2.0.0.js"></script>
<script src="http://code.jquery.com/jquery-migrate-1.1.1.js"></script>

How to Use It

jQuery 2.0 is intended for the modern web; we’ve got jQuery 1.x to handle older browsers and fully expect to support it for several more years. If you want, you can serve 2.0 to newer browsers and 1.9 to older ones using our conditional comment trick, but that is not required. The simplest way to support older browsers is to use jQuery 1.x on your site, since it works for all browsers.

With the release of jQuery 2.0, there are a few environments where the jQuery team will no longer support use of the 1.x line because 2.x is a far better choice. These are typically non-web-site scenarios where support for older IE isn’t relevant. They include:

  • Google Chrome add-ons
  • Mozilla XUL apps and Firefox extensions
  • Firefox OS apps
  • Chrome OS apps
  • Windows 8 Store (“Modern/Metro UI”) apps
  • BlackBerry 10 WebWorks apps
  • PhoneGap/Cordova apps
  • Apple UIWebView class
  • Microsoft WebBrowser control
  • node.js (combined with jsdom or similar)

Many of these environments are themselves a work in progress, and have unique sets of rules or restrictions that are different from the ones typically found when jQuery is used for browsers on Internet web sites. Although we aren’t able to test regularly in all of these non-browser scenarios, we’d like to hear about your experiences in using jQuery with them. Even better, we’d love for the communities supporting these environments to pool and share their knowledge about how to use jQuery 2.0 there.

How 2.0 Changed

Here are some highlights of the changes that jQuery 2.0 brings:

No more support for IE 6/7/8: Remember that this can also affect IE9 and even IE10 if they are used in their “Compatibility View” modes that emulate older versions. To prevent these newer IE versions from slipping back into prehistoric modes, we suggest you always use an X-UA-Compatible tag or HTTP header. If you can use the HTTP header it is slightly better for performance because it avoids a potential browser parser restart.

Reduced size: The final 2.0.0 file is 12 percent smaller than the 1.9.1 file, thanks to the elimination of patches that were only needed for IE 6, 7, and 8. We had hoped to remove even more code and increase performance, but older Android/WebKit 2.x browsers are now the weakest link. We’re carefully watching Android 2.x market share to determine when we can cross it off the support list, and don’t expect it to take very long.

Custom builds for even smaller files: This feature has been greatly refined and extended since its debut in jQuery 1.8. You can now exclude combinations of 12 different modules to create a custom version that is even smaller. A new minimal selector engine, basically a thin wrapper around the browser’s querySelectorAll API, lets you shrink the build to less than 10KB when minified and gzipped. See the README for instructions on how to create a custom build, and remember that any plugins you use will also need to stick to the subset you select.

jQuery 1.9 API equivalence: jQuery 2.0 is API-compatible with 1.9, which means that all of the changes documented in the jQuery 1.9 Upgrade Guide have been applied to jQuery 2.0 as well. If you haven’t yet upgraded to jQuery 1.9, you may want to try that first. Be sure to use the jQuery Migrate plugin.

The full record of changes can be found in the changelog below, and in the list of commits on GitHub.

What’s Next

In keeping with our pledge to minimize API divergence between the 1.x and 2.x branches, we’ll be releasing a jQuery 1.10 within a couple of months that incorporates the bug fixes and differences reported from both the 1.9 and 2.0 beta cycles. In the future, we will be maintaining feature parity between 1.10 and 2.0, 1.11 and 2.1, etc. Patch releases will happen in each branch on their own schedule, based on team resources and severity of any reported bugs.

Please do try this new release with all your web sites and HTML apps. If you find problems, create a minimal test case (preferably using a site like jsFiddle or jsbin) and submit it to our bug tracker. We’re particularly interested in situations where jQuery 1.9.1 behaves differently than jQuery 2.0.0, since that’s something we’ve tried to avoid.

Who Helped

jQuery 2.0 has been 10 months in the making, a product of the jQuery Core team: Julian Aubourg, Corey Frang, Oleg Gaidarenko, Richard Gibson, Michal Golebiowski, Mike Sherov, Rick Waldron, and Timmy Willison. Oleg and Michal joined the team during the 2.0 odyssey; we’re glad to have them aboard.

Many thanks to the other jQuery team and community members who contributed fixes: Steven Benner, Pascal Borreli, Jean Boussier, James Burke, Adam Coulombe, Tom Fuertes, Scott González, Dmitry Gusev, Daniel Herman, Nguyen Phuc Lam, Andrew Plummer, Mark Raddatz, Jonathan Sampson, Renato Oliveira dos Santos, Ryunosuke Sato, Isaac Schlueter, Karl Sieburg, Danil Somsikov, Timo Tijhof, and Li Xudong.

To those of you who tested the betas and reported bugs, we’re especially thankful for your help since it helped to make the release more solid and stable.

How You Can Help

Please, participate! Try the code (especially the betas), file good bug reports with clear test cases, contribute patches. Write or edit documentation. Come to the jQuery Conference Portland in June and mingle with other jQuery-ites. Visit contribute.jquery.org to learn how to get involved with the project.

You can also become a jQuery Foundation member to support our efforts and get some fabulous gifts in the process!

jQuery 2.0.0 Changelog

Ajax

Attributes

Build

Core

Css

Deferred

Effects

Event

Manipulation

Selector

Support

Traversing

Please do not report bugs in the blog comments! Instead, read the blog post for details on how to report bugs.

99 thoughts on “jQuery 2.0 Released”

  2. panique on said:

    Awesome! But how long will the 1.x branch be maintained ? As some countries still have up to 30% IE8/7/6 market share (Global 6%-7%, according to W3C) i would love to hear your plannings on this. Thanks for your excellent work, jQuery team!

  3. Daniel Figueiredo on said:

    I have always liked to see charts, percentages and absolute difference in size of file and performance of code in libraries that I use.

    For a long time the release notes of new jQuery versions have removed these kind of information, but I would really appreciate those informations coming back on the notes. And I guess thousands other developers would too.

    I don’t know the exact complexity involved for this task, but I guess that an automated job on grunt could resolve this problem, and it would be great information to have.

    Best regards,

    Daniel

  6. Iris on said:

    Howdy just wanted to give you a quick heads up. The words in your content seem to be running off the screen in Firefox. I’m not sure if this is a formatting issue or something to do with web browser compatibility but I figured I’d post to let you know. The design look great though! Hope you get the issue fixed soon. Kudos

  7. Martijn on said:

    No IE7/8 Support. EPIC FAIL.

    How the fuck did this get through? It’s not the place of a framework to decide which browsers are in scope and which aren’t. Needless to say, probably almost noone will upgrade to 2.0, if they take themselves seriously as web developers.

    jQuery team, I suggest you look back at this horrible mistake and support IE7/8 sooner rather than later.

  9. Mark on said:

    Works great for my use case – phonegap on android 4.2.2 for corporate applications. Was looking at Zepto (which doesn’t work natively with all my plugins) until I spotted this.
    Thanks guys :)

  12. dmethvin on said:

    @DaveH, it seems unlikely the Android 2.x market share will fall that quickly. On the other hand, I expect it to fall a lot faster than IE6/7 market share, which has taken a decade. I believe there are still (crappy) Android 2.x phones being sold today, but phones generally have a 2-3 year lifespan. We’ll just have to watch it and decide when it makes sense, just like for 1.x support.

  14. Brad Metcalf on said:

    Getting a little tired of reading rants everywhere that people can’t upgrade because they need to support everyone running IE 6,7,8. I got to thinking about it and it is safe to say this group of users is least likely to be technically inclined if they don’t even bother to do an update or switch browsers entirely.

    This is good news as this would indicate they are extremely unlikely to be using a user agent spoofer. So all you have to do is write a PHP, Python, Rails, JS, or whatever script that detects the user agent’s version. If it is IE 6,7, or 8 then have it load 1.9.1 in the header. Anything else 2.0. Took my 2 minutes to do and in this case I doubt it will fail me.

  15. Stifu on said:

    @Brad Metcalf: or you could go for the safer and simpler solution recommended by the jQuery team, using conditional comments.

  16. tward on said:

    @Brad Metcalf: I still need to support IE7 and 8 because the U.S. Government doesn’t move that fast when upgrading…

    I just don’t understand what people are ranting about when 1.9 will still work just fine for IE 6/7/8, it took 5 minutes to make my pages support both 1.9 and 2.0 of jQuery….

  18. Martijn on said:

    @Stifu
    That’s not the problem. Of course there’s 1.9, but the two version WILL go out of sync in terms of their features and bugfixes. It’s just in the nature of maintaining two current versions of a product. Another problem is, mark my words, 1.9 will be frozen at some point, at a time when IE8 support is still neccesary.

    At this point, the jQuery team will state “just use 2.0 for those new features”. And you’re screwed.

    I think it’s not up to a framework to decide when versions of a browser go obsolete. Proven by the existence of 1.9, there’s a huge demand for oldIE support, but hard-headedly calling the deprecatable version 1.9 is just a big in-your-face sign that it will no longer be supported at some arbitrary point in the near future.

    JUST call both versions 2.0, a “normal” version and a “light” version. Then this whole discussion would not exist, because both versions are the latest one.

    CUSTOM BUILD is another perfect apportunity to add in (or leave out) certain features like oldIE support. But noooo, oldIE had to be moved to a dark corner in an “old” version of the framework.

  19. Martijn on said:

    @jQuery Rocks
    I agree, there are apps using jQuery that have to demand for IE7 or IE8 support. Not even IE9 support (hey, jQuery Team, won’t you remove that too please?…)
    But something like this should be solved with CUSTOM BUILDS, not forcing developers to an “old” version of the framework, which *will* at some point no longer be supported.

  20. Martijn on said:

    “or you could go for the safer and simpler solution recommended by the jQuery team, using conditional comments.”

    That’s just falling to your knees and begging hopelessly for problems. Once the 1.9 and 2.0 branche start to go out of sync, and they WILL, you’re in for a treat. If you wanna be futureproof, DO NOT include two version of the same framework, seriously.

  21. Martijn on said:

    “Also remember that production web sites should be requesting a specific version from any CDN; using a non-specific version like /2/ or jquery-latest.js is considered harmful to your web site’s health and performance.”

    Haha, and today I realize why they always emphasize this. Doing this will break your site in IE7 and IE8 ;)
    Just saying :)

  22. Dennis on said:

    Any possibility of a fallback js, which includes IE8 support? There’s no upgrade to IE9 for Win XP.

  23. Stifu on said:

    @Martijn: “I think it’s not up to a framework to decide when versions of a browser go obsolete.”

    It’s totally up to them to decide what they support. They don’t decide or claim something is obsolete, they just decide to stop supporting it (which they haven’t yet, for oldIE). Following your logic, jQuery should support IE<6 or Netscape 4, because they shouldn't dictate which browser we use. Actually, the jQuery team is being very considerate to make everyone happy, and make the transition as smooth as possible. They're both thinking of the future (or should I say present?), and making sure developers for IE6-8 aren't left out just yet.

    Besides, I don't really see what's the big deal with having to use an older jQuery version on your sites that target IE6-8. Most developers wouldn't be able to tell the difference between jQuery 1.4 and 1.9. The main problem would be potential plugin compatibility issues, but even that can be resolved one way or another.

  24. Kamran Shahid on said:

    I understand about the backward compatibility problem wiht older IE versions but it should atleast support IE 8

  25. joe on said:

    Why don’t kick off IE6 – IE7 first ?

    IE8 is the latest version of MSIE in Windows XP and still have a lot of market share.

    According to Statcounter, there are 18% market share of IE8, but only <3% market share of IE7 or below.

  26. joe on said:

    Update: Market share according to statcounter,
    For Jan 13 – Apr 13,
    10.72% of market share for IE8
    <2% for IE7 or below

  27. Stifu on said:

    They’re not just removing support for IE6-7, but also IE8, for technical reasons. It wouldn’t make much sense / help much to remove support for just IE6-7, as IE8 has similar limitations. That is to say they’d still have to keep most oldIE hacks in place if they wanted to keep IE8 support.

  28. Brad Metcalf on said:

    As I understand it users will still get IE 6-8 support for jQuery through the 1.x branch. All 2.x will be compatible depending on versions. Such as the way 2.0 and 1.9.1 are compatible. The difference is 2.0 does a faster kill off on browsers on there way out or browsers most likely not to be supported for the application being developed anyways. As 1.x progresses I wouldn’t doubt they will start phasing out old browsers. But it will be a more slow kill off, you know when the browsers have very little market share. The comments on other sites are getting pretty crazy because the initial thought is jQuery isn’t giving you an option, when in reality they are giving developers a better option.

    I am still in favor of UA detection over conditional comments in this process at the current state of browser phase outs. Like I mentioned IE users using old versions are very unlikely to be sending an incorrect UA header. If it happens, it is going to be a very rare case. I can’t be so confident this will be bulletproof for future phase outs though. And I am also on the fence about conditional comments and future headaches this could cause. But my preferred method was mentioned with the intentions of pointing out this could be a simplistic way to upgrade, have wide support, and hopefully be a case UA detection is dependable. As far as seeing if a browser is capable of something users should still use feature detection over UA detection.

  29. Brad Metcalf on said:

    Also, I use both methods of UA detection and conditional comments after the UA detect just to be safe. My worries about CC failing me is for future browsers not doing a proper detection if the browser has parsing issues.

  30. Brad Metcalf on said:

    Hate how you can’t do an edit to a comment on here. What I meant by parsing issue is conditional commenting is an IE feature. Non IE browsers ignore them. But in a case they ignore the commenting tags and not the script tags then you will have the possibility of both being attached to the page and causing conflicts.

  31. Stifu on said:

    @Brad Metcalf: so you’re worried some browsers will stop handling HTML comments properly. This basically can’t happen. If such a browser existed, it wouldn’t work with loads of sites, assuming it wouldn’t simply be completely useless. And the browser would have to get fixed very fast if they want to keep users. If you can’t trust a browser to properly handle HTML comments, you can’t trust it to do anything right. You shouldn’t code around such crazy scenarios. Actually, UA detection is much more likely to fail.

  32. jQuery Friend on said:

    It’s really Great that jquery starts to unsupport old and legacy browsers and OSs like IE and Android 2.x.
    Hope other librarys switch to this solution too.

    “The world wide web stops it’s modernity cause of clients running old machines…”

  33. Toni L on said:

    I understand the rant about Internet Explorer, but I’d really recommend that people would start to push people to install the latest Google Chrome, Mozilla Firefox or other modern browser to their users. It should be a priority to support developement. Even banks constantly raise the bar for users browser, just because of the security issues.

    And if you decide to support the ancient browsers, don’t forget to add that on your project estimate. ;)

  34. Etienne - Lotus Marketing on said:

    Awesome. Going to switch my existing websites to v2 and see how it goes. Keep it up guys!

  35. bois rond on said:

    currently switching website to v2 and .. perfect migration so far.

  37. filipvb on said:

    IMHO, It was at least 2 years too early to fork the code; – the marketshare of IE8,7,6 is still too high: http://goo.gl/I898M
    Some 15% code size reduction is not worth for such a big change.

  38. Anand on said:

    Hello Jquery team,

    I am creating a web application using Jquery for some support people. You can understand support teams can work on any browser based on the problem. Can you please suggest me which version is suitable for me. After reading this it confused me more. Please suggest proper version and any link.
    Thanks you for the effort and Help,
    Anand

  39. Ryan Wheale on said:

    While I agree that there are still a large number of people using old IE, this is due in part to the fact that we developers continue to build things which will work in those browsers. If we start to move away from supporting those old browsers, eventually the end user (or IT manager) will get a clue and upgrade to a browser which follows specifications. It is our responsibility to force this change, or else lay folk and hard-headed IT managers will never make the change.

  40. Matthew Kaufer on said:

    Hi guys,
    I’m trying to use jQuery 2.0.0 in my Windows 8 store app. The app works fine, but I get the following error when I run the app validation kit, which is required in order to publish an app to the store.

    FAILED
    Bytecode generation
    Error Found: The bytecode generation test detected the following errors:
    File \?C:Program FilesWindowsApps25899MatthewKaufer.TrigonometricTriangleSolver_1.0.0.4_neutral__2hr1s851qz6dejsjquery-2.0.0.js has JavaScript syntax or other problems.
    Impact if not fixed: As a performance optimization to accelerate JavaScript execution time, JavaScript files ending in the “.js” extension generate bytecode when the app is deployed. This optimization significantly improves start-up and ongoing execution times for JavaScript.
    How to fix: You may need consider one or more of these steps to fix the issue:
    – Ensure that event logging is enabled
    – All JavaScript files are syntactically valid; otherwise exclude the respective files from the package
    – Please note that you should uninstall all previous versions of the app before deploying
    Otherwise exclude the respective files from the package.

    Basically, it doesn’t like the code for some reason or another. Does anyone here have a fix for that?

  41. Joshua Holden on said:

    I too think this was a bit too soon. Yes you always need to be moving forward and us developers would love to use the latest and greatest as soon as possible but IE8 still holds a large chunk of the market share. You cannot expect that developers start building apps on a platform a company cannot use / support. It’s a slow process to change standards in any large company and for many good reasons.

  42. Fernando on said:

    I am happy to see the jQuery team is looking forward and has decided to use jquery’s well deserved influence to push development to take advantage of the new browsers capabilities. I am sure reducing the size of the framework is not the main reason for this decision. More over, support for IE on version 1.x will continue so let’s all look ahead and make de web better. Congratulations!!!!!

  43. DigitalZoomStudio on said:

    Hello

    I have a problem with this ” You can now exclude combinations of 12 different modules to create a custom version that is even smaller.”

    Why would you do that ? Maybe the client will include a small version of jquery and your plugin requires a module not included. How can you explain him that he needs that specific module and to change the jquery version if he is noob ?

    I vote for full jquery every time.

  44. Niccolò Brogi on said:

    I don’t fully get how it would make sense to stop supporting 25% of users for 15% in size reduction, with no added benefits.

    I’m sure I’m missing something. Can somebody illuminate me?

    Thanks!

  45. Carl White on said:

    Essentially over the years code is added to support/hack/circumvent issues in older deprecated browsers which can be removed which reduces size and improves performance.

    They do say to continue using the ‘API compatible’ 1.9.x library for websites that *require* support for these older browsers, but some frameworks for app development etc, do not require this so the v2.0.0 framework is smaller, lighter and faster. Hope this helps.

  46. Joe Zimmerman on said:

    How are people not understanding this?

    There are a ton of environments where you will never run into IE8-, such as the ones listed in the article:
    Windows 8 apps
    Chrome OS apps
    Firefox OS apps

    So why use a jQuery version that supports these browsers in these environments. 2.0 is moreso built for these situations and for web apps that the developers have decided not to support these browsers anyway. If you need to support IE6/7/8, then stop complaining about 2.0 being released and keep using 1.x.

    Also, for those complaining about the build process where you can strip out modules: this is not for your clients’ websites. This is for sites that you completely control and maintain. Of course you don’t give a stripped-down jQuery to someone who doesn’t know what they’re doing but will still add plugins that depend on jQuery. But people like you aren’t the only web developers in the world.

  47. Breno on said:

    +1 Joe Zimmerman! The negative commentors seem to be missing the point entirely. uoting the second sentence of this blog post by dmethvin:

    “In return it is smaller, faster, and can be used in JavaScript environments where the code needed for old-IE compatibility often causes problems of its own.”

    So clearly it is not just about a smaller file size. In my particular projects, running faster and leaner code, and cutting out the old browser quirks are the main headliners for me. Who cares about library file size when it’s primed in the cache from a CDN haha.

    If you have even the slightest requirement to support older IE browsers, stick with 1.X. Simple!

  48. Rob on said:

    This is ridiculous. The primary reason for the success of JQuery is cross platform scripting, and for apparent religious reasons the team just dropped support for a large market share of browsers.

    JQuery 2.0 should have been forked to JQuery Compact or some other branch if there is such a need for it. By calling it the “latest” version, it causes major headaches for those who require “true” cross platform scripting – ie. ALL commercial websites exposed to the general public.. For instance I can no longer use Nuget to acquire the aforementioned new versions of the 1.x branch, because it is going to want to install 2.x now.